-
Notifications
You must be signed in to change notification settings - Fork 633
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up HTTP async iterator code #411
Conversation
2663596
to
a43e200
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It needs backpressure semantics.
2c056ba
to
554f941
Compare
@ry seems with this implementation, there is always going to be either 0 or just 1 element in sendQueue/recvQueue? |
@kevinkassimo I think so too, but I haven't been able to come up with a simplification. |
I'm sorry but this still creates an unbounded queue. Imagine multiple physical TCP connections coming in while no requests are being processed. |
I'll write something myself |
See 29f3e8e |
I realize there is one big issue with this, which is that one tcp connection can block processing of others. |
... which has been fixed now. |
715075b
to
6bcd5cb
Compare
Looks fine. I’m slightly worried it doesn’t work when you respond to a request out of order? But I think we have tests for that... |
That's no longer possible, because no new requests will be accepted on the same connection before the previous one has done responding. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Is this PR may fix the issue of malformed or encrypted mime headers? Returning an error 400 if the request can't be properly read. |
@zekth I don't know. Is there a test for this issue? |
Not atm because we use But i can write some like done in : https://github.com/denoland/deno_std/blob/master/http/racing_server_test.ts For ref: denoland/deno#2346 |
This PR results in a 1/3 reduction of req/sec: master:
this branch:
Latency also seems exceptionally problematic, effectively x100. |
@kevinkassimo pipelining hasn't been removed but I'll look into it. |
@kevinkassimo Can you try again? I think the latest patch should remove the unfair scheduling that was introduced by the MuxAsyncIterator and restore overall performance. However I'm still seeing pretty bad max-latency values. Note that it's strictly the maximum latency that is quite bad. The overall distribution (the one you get with |
It could also be due to v8 doing some optimizing after the benchmark has started. I'm seeing much better max-latency numbers on the second and subsequent runs. |
@piscisaureus Seems performing better than master now. This branch:
|
There is another small issue I noticed: it seems under 500 concurrent connections our HTTP server would die silently... Might be unrelated to this PR though:
(Actually on master this would result in a panic on
Not so sure why under this PR this panic does not occur but the server still silently dies) |
@ry I think async test may not actually be running |
@kevinkassimo I think we may not be dealing with EMFILE errors properly. What happens if you increase the ulimit on your system? |
Or running out of ephemeral ports. |
I will land this branch now and update the submodule in master: denoland/deno#2378 |
cc @kevinkassimo @keroxp